Support interface module bug submitter

ABSTRACT

A method for submitting a bug report utilizes a bug submission module to request a bug submission service from a first support host using a Support Interface Module for communicating with the first support host. The bug submission service includes a list of data to be collected and the return address of a second support host. The first support host also includes a support services resource. The bug submission module receives the requested bug submission service from the first support host using the Support Interface Module and collects data based on the list of data to be collected. The bug submission module then sends the collected data to the return address of second support host using the Support Interface Module.

CROSS-REFERENCES

[0001] This is a continuation-in-part of U.S. patent application Ser.No. 09/______ filed Nov. 9, 2001, in the name of inventor Maarten W. 'tHooft, entitled “Support Interface Module”, commonly assigned herewith.

FIELD OF THE INVENTION

[0002] The present invention relates generally to the field of computerscience. More specifically, the present invention relates to a supportinterface module bug submitter over which channels of information canflow between an application interface and an external support service.

BACKGROUND OF THE INVENTION

[0003] Despite the advancement of technology, users continue toexperience problems with computer systems. Support may then be needed.Support may include a number of services including an explanation offeatures or the trouble shooting of problems. Traditional support takesmany forms. For instance, support may take the form of a user manual.Many users find these little help at all if they can even locate themanual when they need one. To combat this, support may take the form ofan embedded help function. This may be query or menu driven. Again thisis a form of self-help and it is limited to the time when the functionis fixed in the application. To reduce time dependency and memorydemands, support may take the form of a dedicated help server externalto the application. Increasingly, applications and users are connectedtogether by networks such as the Internet. In this case, the user leavesthe application and, via the network, contacts the help serverindependently and seeks the support that they need there. If this doesnot prove adequate, the user may phone a dedicated help provider andspeak with one of their representatives or listen to their automatedservice. Individually or in combination, traditional forms of supportmay often prove unsatisfactory to the user.

[0004] A bug is a persistent error in a software or hardware. One way toget rid of the bug it to modify the program, usually with a softwarepatch for software. A bug report consisting of data describing the errorthat occurred, may be submitted to a support provider or the softwaredeveloper. The support provider once notified of the bug, may thenprepare a software patch or a new version of the software removing thebugs previously found.

[0005] A definite need exists for a bug submission module allowing theuser to select how and where a bug report is submitted. A primarypurpose of the present invention is to solve these needs and providefurther related advantages.

BRIEF DESCRIPTION OF THE INVENTION

[0006] A method for submitting a bug report utilizes a bug submissionmodule to request a bug submission service from a first support hostusing a Support Interface Module for communicating with the firstsupport host. The bug submission service includes a list of data to becollected and the return address of a second support host. The firstsupport host also includes a support services resource. The bugsubmission module receives the requested bug submission service from thefirst support host using the Support Interface Module and collects databased on the list of data to be collected. The bug submission modulethen sends the collected data to the return address of second supporthost using the Support Interface Module.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated into andconstitute a part of this specification, illustrate one or moreexemplary embodiments of the present invention and, together with thedetailed description, serve to explain the principles and exemplaryimplementations of the invention.

[0008] In the drawings:

[0009]FIG. 1 is a block diagram that illustrates a Support InterfaceModule bug submission system according to a specific embodiment of thepresent invention;

[0010]FIG. 2 is a block diagram that illustrates a bug submission moduleand the Support Interface Module of FIG. 1 according to a specificembodiment of the present invention; and

[0011]FIG. 3 is a flow diagram that illustrates a method for a bugsubmission according to a specific embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0012] Embodiments of the present invention are described herein in thecontext of a support interface module bug submitter. Those of ordinaryskill in the art will realize that the following detailed description ofthe present invention is illustrative only and is not intended to be inany way limiting. Other embodiments of the present invention willreadily suggest themselves to such skilled persons having the benefit ofthis disclosure. Reference will now be made in detail to exemplaryimplementations of the present invention as illustrated in theaccompanying drawings. The same reference indicators will be usedthroughout the drawings and the following detailed descriptions to referto the same or like parts.

[0013] In the interest of clarity, not all of the routine features ofthe exemplary implementations described herein are shown and described.It will of course, be appreciated that in the development of any suchactual implementation, numerous implementation-specific decisions mustbe made in order to achieve the developer's specific goals, such ascompliance with application- and business-related constraints, and thatthese specific goals will vary from one implementation to another andfrom one developer to another. Moreover, it will be appreciated thatsuch a development effort might be complex and time-consuming, but wouldnevertheless be a routine undertaking of engineering for those ofordinary skill in the art having the benefit of this disclosure.

[0014] In accordance with one embodiment of the present invention, thecomponents, process steps, and/or data structures may be implementedusing various types of operating systems, computing platforms, computerprograms, and/or general purpose machines. In addition, those ofordinary skill in the art will recognize that devices of a less generalpurpose nature, such as hardwired devices, field programmable gatearrays (FPGAs), application specific integrated circuits (ASICs), or thelike, may also be used without departing from the scope and spirit ofthe inventive concepts disclosed herein.

[0015] Turning first to FIG. 1, a block diagram of a bug submissionsystem 100 is shown. The system 100 includes a host system 102, a firstsupport host 104, and a network 106 connecting the host system 102 tothe first support host 104. One of ordinary skill in the art willrecognize that the network 106 may take one of many forms. For the sakeof clarity, these will not be presented here. The host system 102includes at least one application having an interface 108 for the user.The application may also take many forms including word processor ornetwork browser. Likewise, the outward manifestation of the interface108 may take many forms but will typically be a graphical userinterface. The interface 108 includes a bug submission module 110 thatenables the user of the application to submit a bug report for aparticular module 111 having a bug. The bug submission module 110 isdescribed in more detail below. In addition, the bug submission module110 communicates with and through a support interface module (SIM) 112.The SIM 112 may be integral to the application, to the host system 102,or to some combination of both. In some contexts, the SIM 112 may not bereferred to as a module but will still perform the same functions. TheSIM 112 provides the infrastructure over which channels of informationcan flow between the host system 102 and the first support host 104. Thefirst support host 104 includes a support services resource 114 that iscalled upon to help submit the bug. In one specific embodiment, thesupport services resource 114 includes a bug submission service having alist of data to be collected on the host system 102 and the returnaddress of the support host that the list of collected data will be sentto when that service is selected. The collected data can either be sentto the first support host 104 or to a third party support host, such assecond support host 116. The destination of the collected data dependson the user's choice of service. The user should only view the result ofthe collaboration between the bug submission module 110 and the SIM 112.The result is a bug submission presence within the application itself.

[0016] In order for the SIM 112 to configure and manage thecommunication of data from the bug submission module 110 to the firstsupport host 104, the SIM 112 may need information such as the addressof the support services resource 114, the type of communication protocolto be used, the port to contact and the eligibility of use of thesupport services resource 114. The SIM 112 can obtain the necessaryinformation in at least one of three different ways. Two of thesemethods rely on the use of description facilities while the thirdrequires no description searching.

[0017] According to one embodiment, the SIM 112 can contact a supportservices registry for information on a service. The location of thesupport services registry can be predetermined or an address for theregistry can be provided by an outside source. Among other information,the registry will contain information on whether a service exists, whereit is located, and who may use it.

[0018] According to another embodiment, the SIM 112 may contact aservice description servlet at the instruction of the bug submissionmodule 110. The SIM 112 looks in a location specified by the bugsubmission module 110 for information regarding a particular service.The service description servlet will then pass on the information in aformat similar to the one found on the support services registry.

[0019] According to a yet another embodiment, the SIM 112 may, onoccasion, find that the bug submission module 110 itself contains all ofthe information needed. If so, the SIM 112 utilizes the informationprovided by the bug submission module 110 without reference to aregistry or description service.

[0020] There are a number of general attributes that one might want theSIM 112 to exhibit. If one or more of these attributes are contrary toone another or to the specific environment, then they can be deleted ormodified. One would prefer that the architecture of the SIM 112 be ableto provide seamless communication between the user and the supportservices resource 114. Further, one would prefer that the SIM 112 beaware of the networking environment in which it resides. This awarenessmight include knowing which ports are accessible, what the variouslatencies are, what bandwidth is available, and what the current trafficload is. Further still, one would prefer that the SIM 112 be able toensure the security and integrity of all of its communications with thefirst support host 104. Either continuously or on demand, one wouldprefer that the user be able to monitor the activity of the SIM 112. Onewould also prefer that the SIM 112 be able to correct for failedcommunication links or at least be able to present the user with optionsin such an event. The SIM 112 may communicate with one or more of anynumber of communications protocols in either or both a synchronous andan asynchronous mode.

[0021] Turning now to FIG. 2, a block diagram of the bug submissionmodule 202 and the Support Interface Module 204 of FIG. 1 is shown. TheSIM 204 is shown to include a session handler 206, at least one session208, a transport handler 210, and at least one transport 212 for eachsession 208. Each component plays a role in the process of communicationbetween the bug submission module 202 and the support services resource114 of FIG. 1. Each component may be independent of one another or theSIM 202. Conversely, the function of each component may be combined inwhole or in part without departing from the inventive concept disclosedherein. The session handler 206 provides coordination of the one or moresessions 208 that are ongoing. The transport handler 210 providescoordination of the one or more transports 212 per ongoing session 208.

[0022] One example of a communication process by the bug submissionmodule 202 assumes that a user makes a request, then the bug submissionmodule 202 initially processes this request. It may be the case that thebug submission module 202 can handle the request alone. When the bugsubmission module 202 can not handle all or some portion of the requestalone, then it contacts the SIM 204. The SIM 204 passes the request tothe session handler 206 which approves the request and generates atleast one session 208 for the request. The session 208 in turninitializes the transport handler 210 for the communication required todeal with the request. The transport handler 210 generates at least onesuitable transport 212 for the session 208. The transport 212 sends datato and/or receive data from the support services resource 114 of FIG. 1.It may be the case that the transport handler 210 is instructed toredirect the communication. In such a case, the transport handler 210may generate a new transport 212 and terminate the original transport212. Through its API, the session 208 cooperates with the bug submissionmodule 202 to satisfy the user's request. Consequently, after theinitial request, all subsequent communication by the bug submissionmodule 202 for the request is with the session 208 and not with thesession handler 206. When the request of the user is either satisfied orwithdrawn, some or all of the sessions 208 and the transports 212 thatwere generated for that request may be terminated. Multiple requests maybe processed in sequence or in parallel.

[0023] As above with the SIM 204 in general, there are a number ofgeneral attributes that one might want the components of the SIM 204 toexhibit. If one or more of these attributes are contrary to one anotheror to the specific environment, then they can be deleted or modified.For example, one would expect that the session handler 206 would beaware of all of the sessions 208 that are generated. Further, one wouldprefer that the session handler 206 hold data about the host system 102and the network 106 of FIG. 1. Also, one would prefer that the sessionhandler 206 be aware of the network activity originating from the hostsystem 202. In addition, one would prefer that the session handler 206use this network activity awareness to scale its own network activity toavoid significant performance loss to the host system 102. It would alsobe preferred that the session handler 206 to be able to provideinformation regarding or correction of communication failures. Furtherstill, one would prefer that the session handler 206 be able to providestatus info for each session 208 either continuously or on demand.

[0024] It may be the case that a host system 102 includes multiple SIMs204. In such a case, it may be necessary to coordinate the individualSIMs 204. This may be accomplished in a number of ways known to one ofordinary skill including disabling all but one of the session handlers206 and placing the non-disabled session handler 206 in control of allof the SIMs 204. Another technique would be for the multiple sessionhandlers 206 to hold an election to determine which session handler 206will control the multiple SIMs 204.

[0025] With respect to the sessions 208, although there may be multiplesessions 208 running in series or in parallel, the individual sessions208 may not be aware of one another. Further, one would prefer that thesessions 208 have a finite length and that either or both the sessionhandler 206 and the bug submission module 202 be able to terminate thesession 208. One would prefer for the session 208 to controlcommunications between the SIM 204 and the bug submission module 202.

[0026] With respect to the transport handler 210, one would expect thatthe transport handler 210 would be aware of all of the transports 212that it has generated. If there are multiple SIMs 204, a first transporthandler 210 may or may not be aware of a second transport handler 210 orthe transports 212 that the second transport handler 210 has generated.Further, one would expect the transport handler 210 to be able tocommunicate using one or more of any number of protocols. One wouldprefer that the transport handler 210 be able to generate diagnosticinformation on the network environment and characteristics and be ableto pass this information on to the session handler 206. One would alsoprefer that the transport handler 210 be able to report errors andexceptions to the session handler 206.

[0027] With respect to the transports 212, although there may bemultiple transports 212 in series or in parallel, the individualtransports 212 may not be aware of one another. It may be the case thatthe transport 212 is channel dependent such that when the channel failsthe transport 212 ends and a new transport 212 may have to be generatedby the transport handler 210 to complete the failed communication.

[0028] According to one embodiment of the present invention, the BugSubmission Module 202 provides the user with several options. Forinstance, prior to submitting the bug, the user is presented with anopportunity to troubleshoot the problem (which will also automate theproblem description), and review and approve any data collected. If theuser chooses to submit the problem, an acknowledgement of the submissionis provided. Once the context of the bug (the relevant module) is known,the Bug Submission module 202 presents the SIM services available forthat module. Thus the SIM 204 may be used to invoke other arbitrary SIMservices in the process of submitting a bug. This allows for morefeatures to be embedded dynamically into the Bug Submitter module 202.

[0029] The Bug Submitter Module 202 submits its bug report through theSIM 112 and network 106. One of ordinarily skill in the art will realizethat there are many ways in which the SIM 112 may communicate withnetwork 106. For example, SIM 112 may submit the bug reports via SOAP(over HTTP and SMTP). Additionally, the bug submission module 202 mayprovide an API for module developers to use their own transportmechanisms. According to one embodiment, the bug submission module 202may not use SOAP but may simply open a Socket connection to transportthe data to a support host. This would allow the use of third partytoolkit vendors for an easy and extensible mechanism for transportingdata. Since SOAP messaging is not bi-directional, the Bug Submissionmodule 202 may rely on the SIM architecture to provide messageacknowledgements where possible.

[0030] According to one embodiment, the bug submission module 202comprises a receiver (not shown) for receiving a submission serviceusing the SIM 112 to communicate with the first support host 104. Thesubmission service comprises a list of data to be collected and thereturn address of a second support host. A collector (not shown)collects the data based on the list of data to be collected. A sender(not shown) sends the collected data to the second support host 116using the SIM 112.

[0031] The bug submission module 202 may also incorporate a datacollection service and a data delivery mechanism. The data collectionservice provides mechanisms for gathering information commonly requestedby support engineers, as well as a mechanism for module developer to adddata requirements for their reports. The data delivery mechanism mayutilize a portion of a Support Services Interface Module API to transferthe collected data to a destination in the appropriate format.

[0032] According to one embodiment, with respect to the data collectionservice of the bug submission module 202, each report template shouldhave specific information to collect. All automated data collectors mayinclude a collection timeout. A call to retrieve collected data shouldeither return the data when the collection is completed or set the datastate to a failed status. The API for data collection should allow formodule developers to provide custom report templates and data collectionthat follows the previously listed preferences. The collected data mayinclude, by way of example, requests for user supplied data such assteps to reproduce, or support contract information. Such user supplieddata should distinguish empty input from a failure to acquire input. Alldata collected should be associated with a data presenter appropriatefor the user environment.

[0033] According to one embodiment, with respect to the data submissionmechanism of the bug submission module 202, the data may be submittedonly to the destination accepted by the user. Such destination shouldhave at least one transport. However in case of failure, more than onetransport may be used. The transport may specify a protocol and addressfor the transmission of the data. The destination may provideinformation to prove its identity to the user. The destination mayattempt to use alternate transports prior to failing completely. Thedestination may also attempt to confirm transmission. In the event of acomplete transmission failure, the bug submission module 202 shouldallow for retransmission or the specification of a new destination.

[0034] Turning now to FIG. 3, a flow diagram of a method for submittinga bug report according to the bug submission module 202 is shown. In afirst decision block 302, a bug is detected on the host system 102 ofFIG. 1. When a bug is detected, the bug submission module 110 of FIG. 1receives a notification about the presence of the bug. The BugSubmission module 110 then requests a Bug Submission service from afirst support host 104 in block 304. In response to the request, therequested Bug Submission service 110 is received in block 306. TheSubmission Service comprises a list of data to be collected and thereturn address of a support host. In block 308, the bug submissionmodule 110 collects data based on the list of data to be collected asspecified in the requested submission service. The bug submission module110 submits the collected data via SIM 112 to the support host asspecified in the submission service in block 310. The support host mayeither be the first support host 104 or another support host such assecond support host 116.

[0035] According to another embodiment, the SIM may provide for aCollector class (not shown) to developers. Collectors are intended toobtain data from the user or the environment. Those collectors thatretrieve information from the environment (the user's system) will berequired to be able to run more than once, such that if a useraccidentally overwrites the collected data, it can be retrieved onceagain. If it is not possible for the value to change between runs, it isacceptable for the Collector to simply cache and return the last valueobtained.

[0036] According to another embodiment of the present invention, afterall data collection has been done, each piece of data will be presentedto the user. Each piece of data will be associated with a Presenter,either because the data has a known MIME type associated with apresenter, or because the collector has associated this piece of datawith a specific Presenter instance. It is a design goal to keep this APIgeneric enough to be used from the command line.

[0037] One feature of the SIM bug submission module is the ability forthird parties (Support Providers) to leverage the features for theircustomer base and support staff. Developer support may also includeexample codes and extensive base classes where applicable.

[0038] According to another embodiment, all bug reports (regardless ofthe report structure) must be compatible with a to-disk Transportprovided by the SIM bug submission module. Basically this means that thebug report must be able to be saved to a file. The files should bedesigned so that they can be sent using a different user and machinethan that which generated the report.

[0039] While embodiments and applications of this invention have beenshown and described, it would be apparent to those skilled in the arthaving the benefit of this disclosure that many more modifications thanmentioned above are possible without departing from the inventiveconcepts herein. The invention, therefore, is not to be restrictedexcept in the spirit of the appended claims.

What is claimed is:
 1. A method for submitting a bug report, the methodcomprising: requesting a bug submission service from a first supporthost using a Support Interface Module for communicating with said firstsupport host, said bug submission service having a list of data to becollected and a second support host return address, said first supporthost having a support services resource; receiving said requested bugsubmission service from said first support host using said SupportInterface Module; collecting data based on said list of data to becollected; and sending said collected data to said second support hostreturn address using said Support Interface Module.
 2. The methodaccording to claim 1 wherein said support services resource furthercomprises a directory of support host addresses.
 3. The method accordingto claim 1 wherein said second support host return address comprisessaid first support host address.
 4. The method according to claim 1wherein said requesting, said receiving and said sending furthercomprises: receiving said bug submission service request by the supportinterface module; establishing overall control of said bug submissionservice request process; generating at least one session for said bugsubmission service request; initializing communication control of saidbug submission service request process; generating at least onetransport for the at least one session; and transmitting and/orreceiving data via the at least one transport.
 5. A bug submissionmodule comprising: a receiver for receiving a bug submission serviceusing a Support Interface Module for communicating with a first supporthost, said bug submission service having a list of data to be collectedand a second support host return address, said first support host havinga support services resource; a collector coupled to said receiver forcollecting data based on said list of data to be collected; and a sendercoupled to said collector for sending said collected data to said secondsupport host return address using said Support Interface Module.
 6. Thebug submission module according to claim 5 wherein said support servicesresource further comprises a directory of support host addresses.
 7. Thebug submission module according to claim 5 wherein said second supporthost return address comprises said first support host address.
 8. Thebug submission module according to claim 5 wherein said SupportInterface Module further comprises: a session handler for receiving auser request from a bug submission module and for controlling theactivities of said Support Interface Module; at least one sessiongenerated by the session handler for processing said user request; atransport handler initialized by said at least one session for managingcommunications with said first support host; and at least one transportgenerated by said transport handler for communication of said at leastone session with said support services resource.
 9. A host systemcomprising: a Support Interface Module for communicating the host systemwith a first support host having a support services resource; and anapplication having a bug submission module, said bug submitter moduleincluding: a receiver for receiving a bug submission service using saidSupport Interface Module, said bug submission service having a list ofdata to be collected and a second support host return address; acollector coupled to said receiver for collecting data based on saidlist of data to be collected; and a sender coupled to said collector forsending said collected data to said second support host return addressusing said Support Interface Module.
 10. The bug submission moduleaccording to claim 9 wherein said support services resource furthercomprises a directory of support host addresses.
 11. The bug submissionmodule according to claim 9 wherein said second support host addresscomprises said first support host return address.
 12. The bug submissionmodule according to claim 9 wherein said Support Interface Modulefurther comprises: a session handler for receiving a user request from abug submission module and for controlling the activities of said SupportInterface Module; at least one session generated by the session handlerfor processing said user request; a transport handler initialized bysaid at least one session for managing communications with said firstsupport host; and at least one transport generated by said transporthandler for communication of said at least one session with said supportservices resource.
 13. A bug submission module comprising: means forrequesting a bug submission service from a first support host using aSupport Interface Module for communicating with said first support host,said bug submission service having a list of data to be collected and asecond support host return address, said first support host having asupport services resource; means for receiving said requested bugsubmission service from said first support host using said SupportInterface Module; means for collecting data based on said list of datato be collected; and means for sending said collected data to saidsecond support host return address using said Support Interface Module.14. The bug submission module according to claim 13 wherein said supportservices resource further comprises a directory of support hostaddresses.
 15. The bug submission module according to claim 13 whereinsaid second support host return address comprises said first supporthost address.
 16. The bug submission module according to claim 13wherein said means for requesting, said means for receiving, and saidmeans for sending further comprise: means for receiving said bugsubmission service request by the support interface module; means forestablishing overall control of said bug submission service requestprocess; means for generating at least one session for said bugsubmission service request; means for initializing communication controlof said bug submission service request process; means for generating atleast one transport for the at least one session; and means fortransmitting and/or receiving data via the at least one transport.
 17. Aprogram device readable by a machine, tangibly embodying a program ofinstructions readable by the machine to perform a method for submittinga bug report to a support host, the method comprising: requesting a bugsubmission service from a first support host using a Support InterfaceModule for communicating with said first support host, said bugsubmission service having a list of data to be collected and a secondsupport host return address, said first support host having a supportservices resource; receiving said requested bug submission service fromsaid first support host using said Support Interface Module; collectingdata based on said list of data to be collected; and sending saidcollected data to said second support host return address using saidSupport Interface Module.
 18. The program device according to claim 17wherein said support services resource further comprises a directory ofsupport host addresses.
 19. The program device according to claim 17wherein said second support host return address comprises said firstsupport host address.
 20. The program device according to claim 17wherein said requesting, said receiving and said sending furthercomprises: receiving said bug submission service request by the supportinterface module; establishing overall control of said bug submissionservice request process; generating at least one session for said bugsubmission service request; initializing communication control of saidbug submission service request process; generating at least onetransport for the at least one session; and transmitting and/orreceiving data via the at least one transport.